comments
authorJoey Hess <joeyh@joeyh.name>
Fri, 16 Sep 2022 17:40:27 +0000 (13:40 -0400)
committerJoey Hess <joeyh@joeyh.name>
Fri, 16 Sep 2022 17:40:27 +0000 (13:40 -0400)
doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment [new file with mode: 0644]
doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment [new file with mode: 0644]

diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment
new file mode 100644 (file)
index 0000000..f02fd2c
--- /dev/null
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-16T17:10:24Z"
+ content="""
+"file content has changed" is a message from the directory special remote
+when it sees that a file in the directory has a different mtime,size,inode
+tuple (content identifier) than the one that was recorded when importing
+the tree.
+
+Maybe that has something to do with the duplicate files, since they would
+have different inodes. Except, it does try to support that; it can keep
+track of multiple content identifiers for a key, and when there are
+duplicate files, that works in my testing.
+
+I notice that, if I have a directory special remote that was initially
+set up with ignoreinodes=no, and I've imported a tree that way from it,
+I can cause what looks like this problem:
+
+       joey@darkstar:~/tmp/bench/x>git-annex enableremote t directory=../x ignoreinodes=yes
+       enableremote t ok
+       (recording state in git...)
+       joey@darkstar:~/tmp/bench/x>git-annex get 3 --from t
+       get 3 (from t...) 
+         file content has changed
+
+Which seems like a bug that it allows changing it, but I think that the idea was
+that, after changing ignoreinores, the user would re-run git-annex import,
+which would re-import all the files since the content identifier has
+changed. Still, I think that 
+[[!commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7]] didn't consider that
+it could cause a get to fail.
+
+I know you have recently upgraded from a version that defaulted
+to ignoring inodes. Maybe you only need to re-run `git-annex import` from the
+directory remote to fix the problem?
+"""]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment
new file mode 100644 (file)
index 0000000..03c7024
--- /dev/null
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-16T17:32:29Z"
+ content="""
+If I was on the wrong track with my first comment, it would be helpful
+to take a look at the content identifier that is recorded for
+the key, by running:
+
+       git show git-annex:$(git-annex examinekey SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4 --format='${hashdirlower}${key}.log.cid')
+
+The part after the UUID in the output is the content identifier(s). If more
+than one, they are separated by colons. The format of a content identifier
+is "inode size mtime", and the inode will be 0 if it was generated with
+ignoreinodes=yes. So you could then compare the content identifiers
+with the stat of the files in the directory special remote and see if
+something has actually changed.
+"""]]